Release 10.1A: OpenEdge Development:
Programming Interfaces

Connection failures and disruptions

Database connections may fail for a number of reasons:

The database server for multi-user database access is not available—perhaps the network is down or it has not been started or the network parameters are incorrect.
The logical name of the application database already exists for the current session.
The syntax for a connection parameter is wrong.
The connection exceeds the maximum number of users per database (–n).

Table 1–1 lists the default failure behavior for each of the run-time connection techniques.

.

Table 1–1: Connection failure behavior 

Connection technique	Default connection failure behavior
At OpenEdge startup	The OpenEdge session does not run.
CONNECT statement	The procedure executes up to the CONNECT statement where the connection failure occurs. The connection failure raises the error condition for the procedure. OpenEdge error processing does not undo database connections or disconnections. Any database connected in the procedure before the failed database connection remains connected.
Auto-connect	The procedures that contain a reference to the auto-connect database do not run, and a stop or break condition results in the calling procedure.

OpenEdge displays any connection error messages at the point of failure.

Before running a procedure or subprocedure, OpenEdge checks the procedure for database references. For each reference, OpenEdge searches through all of the connected databases, trying to find the corresponding database. If the database is not found, OpenEdge again searches all of the connected databases for an auto-connect list with an entry for that database. If an entry is found, OpenEdge connects the database. If no entry is found, OpenEdge does not run the procedure and raises a stop or break condition in the calling procedure.

Server, network, or machine failures can disrupt an application, even after a successful connection. If a failure occurs while a subprocedure is accessing a database, OpenEdge raises a stop or break condition in the calling procedure.

The following sections present a number of recommendations to help you manage database connection failures and disruptions in an application.

Using CONNECT with NO–ERROR

If you designate a startup procedure with the Startup Procedure (–p) parameter, always use the NO–ERROR option with the CONNECT statement. If a CONNECT statement fails, the NO–ERROR option suppresses the resulting error condition, allowing the procedure to continue executing. Although the NO–ERROR option bypasses ordinary error processing, OpenEdge still displays an error message. For more information on using the NO–ERROR option, see OpenEdge Development: Progress 4GL Handbook .

After a connection failure, if a subprocedure tries to access the unconnected database, OpenEdge raises a stop or break condition in the calling procedure. Therefore, before you execute any subprocedures that access a database, you test whether the database is connected. You can do this with the CONNECTED function.

Using the CONNECTED function

The CONNECTED function tests whether a database is connected. This function helps you to route program control around portions of an application that might be affected by database connection failures and disruptions. This example tests a database connection with the CONNECTED function:

IF NOT CONNECTED(logical-name)   THEN DO:     MESSAGE "CONNECTING logical-name".     CONNECT logical-name ... NO-ERROR.   END. IF CONNECTED(logical-name) THEN RUN procedure. ELSE MESSAGE "DATABASE NOT AVAILABLE".

If the database is not connected, the above code attempts to connect the database. This example only runs the procedure if the database is connected. Auto-connect precludes the use of the CONNECTED function to test for database connections. For more information on the CONNECTED function, see the OpenEdge Development: Progress 4GL Reference .